\section{Considerations for Designing Distributed Systems}


Der Artikel “Considerations for Designing Distributed Systems” leitet kurz mit
 der Historie des Themas verteiltes rechnen ein und sagt dann dass heutige
  Programmiermodelle nicht nur die Verteilung sondern gleichzeitig eine
   Skalierung der Kerne eines Rechners sowie die der ganzen Rechnerfarm
    ermöglichen. Diese Modelle entstehen gleichzeitig mit der Möglichkeit
     Dienste wie Rechenleistung und Datenkapazität selektiv anzumieten. Hohe 
     Anschaffungskosten für Hardware sowie Dienstleistungen zum Betrieb dieser
      entfallen hierbei. Die Idee hinter Cloud Computing ist, dass jeder mit 
      einer Idee, etwas Geld und Programmierkenntnis die Möglichkeit hat 
      skalierbare verteilte Systeme zu entwickeln. Die damit verbundenen 
      sinkenden Anfangshürden werden den Zufluss von Einzelnen und Unternehmen
       fördern, die neue Dienste aufbauen oder bestehende auszuweiten. 
       Bisher waren verteilte Systeme bei einzelnen Unternehmen oder
        Zusammenschlüssen von Geschäftspartnern im Einsatz, jetzt wird es für
         einzelne möglich. Der Autor greift die Idee auf einen Dienst im Web 
         zu erweitern und dadurch eine Wertsteigerung zu erzielen und diesen 
         Dienst wieder zu vermarkten. Er führt dazu die folgenden beiden 
         Beispiele auf.

\subsection{Scenario 1}

Szenario 1 ``Fabrikam Package Tracking Service'' beschreibt einen einfachen zusammengesetzten Dienst.
 Im Bild sind vier Internetdienste dargestellt. ``Duwamish delivery'' ist ein internationaler Paketversand
  und bietet ein gebührenpflichtiges Pakettracing System an. ``Contoso Mobile'' ist ein Mobilfunkanbieter
   der es, gegen Gebühr, erlaubt Textnachrichten ins Mobilfunknetzwerk zu versenden. ``Fabrikam''
    verbindet die beiden genannten Dienste und versendet eine Mobilfunknachricht einen Tag bevor
     ein geordertes Paket geliefert wird. ``Adventureworks'' ist ein Onlineversand und verkauft
      Fahrräder sowie Zubehör. Die Website nutzt dazu den Dienst von ``Fabrikam'' für jedes versendete Paket.
 
\subsection{Scenario 2}

Szenario 2 “Product Finder Service” greift den Gedanken auf verschiedene
 Onlineversandhändler zu durchsuchen um die durch Angebot und Nachfrage 
 entstehenden Preisunterschiede bei den Händlern zu überblicken. “A.Datum” 
 durchsucht dazu “Amazon”, “Ebay”, “CNET” und “Yahoo” und bietet dem Kunden
  die Möglichkeit die Produkte, deren Preis und Verfügbarkeit zu vergleichen.
   Zudem gibt es für den Nutzer die Möglichkeit “A.Datum” zusätzlich ein
    Zeitfenster und eine Preisspanne anzugeben und der Dienst überwacht das
     gegebene Produkt über das Zeitfenster und meldet sich bei Preisänderungen 
     an den Nutzer. Um schnell reagieren zu können werden verschiedene 
     Kommunikationswege benutzt wie E-Mail, Sms und weitere. „A.Datum“ 
     unterhält eigene Mailserver nutzt als Mobilfunkdienst aber 
     „Contoso Mobile“.

\subsection{How to Refer to Customer(s)
In a World of Composite Services}

Etablieren sich solche Systeme wird es schwierig den eigentlichen Endkunden 
von Dienstanbietern zu unterscheiden. Dazu wird folgendes System eingeführt 
Customerx kurz Cx bezeichnet die Entfernung vom Dienst zum Kunden hin. C1 
bedeutet also ein direktes Kunden-Dienst Verhältnis, bei C2 steht ein anderer 
Dienstanbieter dazwischen. Im oben genannten Beispiel 2 wäre der Nutzer von 
„A.Datum“ ein C2 Kunde von „Amazon“. 

\subsection{More Services Will Become Long Running and Stateful}

Dienste sind heute meist nicht zustandsbehaftet und werden von Anfragen oder 
Antworten aufgerufen. Mit dem Wandel zu verteilten Systemen werden viele 
Dienste zu Selbstläufern über eine viel längere Zeit und sind zustandsbehaftet. 
Als Beispiel kann man Szenario 2 betrachten, indem ein Kunde ein Produkt über 
mehrere Monate hinweg überwachen lässt. Beim Design eines solchen neuen Dienstes 
sind mehrere wichtige Dinge die im Auge zu behalten.

\subsection{Publish-and-Subscribe anstatt polling zur Kostenkontrolle}

Auf die Implementierung eines Publish-and-Subscribe Mechanismusses sollte viel 
Wert gelegt werden. Viele der länger laufenden Dienste werden irgendwann 
Informationen an den Benutzer überbringen müssen. Nun sollte man verhindern, 
dass dies nicht über Polling des Benutzers geschieht, da dies unvorhersehbaren 
Traffic und somit Kosten verursachen kann. Als Beispiel lässt ein Benutzer das 
Erscheinen einer DvD beobachten. Diese wird aber nicht früher als in einem Jahr 
erscheinen. Verzichtet man auf solche Mechanismen wie Publish-and-Subscribe 
verursacht das Polling des Kunden bei „A.Datum“, sowie das Polling das „A.Datum“ 
selbst durchführen muss Kosten.  

\subsection{Costcontrol vs Comfort}

Eine Frage die man sich bei Mechanismen wie Publish-and-subscribe stellen muss 
ist, wie und wann kommuniziere ich mit meinem Kunden. Während der Dienst 24 
Stunden lang 7 Tage pro Woche läuft sollte  es der Kunde nicht. Also bleibt zu 
klären wie und wann man sich auf welchem Weg mit ihm in Verbindung setzt. Dazu 
gibt es viele Möglichkeiten zum Beispiel wenn er eingeloggt ist über E-Mail, 
SMS, RSS Feed oder Voice Interfaces. Zusätzlich sollte man sich Gedanken 
darüber machen wann man mit Kunden kommuniziert. Hier sollte es dem Kunden 
möglich sein Regeln anzulegen etwa wie folgt: Kontakt von: 08:00 Uhr bis 22:00 
Uhr bei GMT+1; Ablauf wie folgt: 1. E-Mail senden; 2. 15 min warten auf 
Reaktion; 3. Sms senden; 4. 15 min warten auf Reaktion; 5. Anrufen. Ebenso 
sollten System Ereignisse, wie Shutdowns oder ähnliches, an die Kunden und an 
die genutzten Dienste weitergegeben werden. Auch sollte dem Kunden die 
Möglichkeit gegeben werden solche Ereignisse zu verzögern.

\subsection{Price, Comfort, Control and White-Labeling}

Beim Design sollte man ebenfalls bedenken dass das Kundenspektrum sehr groß 
sein kann und man deshalb seinen Dienst skalierbar halten sollte. Bestenfalls 
vom kostenlosen Dienst bis hin zum komfortablen, mit Kosten behafteten, Service 
für Unternehmen. Direkt verknüpft dazu sollte man sich überlegen ob man 
White-Labeling einsetzt und wenn ja wie. White-Labeling kennt man aus dem
 Bereich der freien E-Mail Anbieter, die jeder von ihnen aus gesendeten Mail
  Anbieter und weitere Werbung anhängen. Im Beispiel Szenario 1 könnte
   „Contoso Mobile“ der Sms ihren Namen anhängen, es dem C1 Kunden überlassen,
    also „Fabrikam“, oder sogar eine Kombination der beiden Dienste.

\subsection{Mechanisms for Servicestate and Errormangement}

Unter Umständen muss es dem Benutzer möglich sein den genutzten Dienst zu
 pollen um an Status Informationen zu gelangen. Dabei sollte man auf bewährte
  Technik setzen, die es ermöglicht Nachrichten auch direkt zu kategorisieren.
   Zum Beispiel RSS oder ATOM Feeds.

Sobald der eigene Dienst andere Dienstanbieter benutzt sollte einem klar sein 
dass dies auch eine Fehlerquelle darstellen kann. Der Anbieter kann sein 
Angebot ändern oder komplett stilllegen. Am Szenario 2 sieht man dies daran 
wenn „Contoso Mobile“ ihren Sms Dienst einstellt. Nun muss man sich eine 
Alternative suchen, nutzt diese Alternative das gleiche Format zur Erstellung 
einer SMS sollte der Umzug einfach zu bewältigen sein.

Im Hinblick auf Fehlerbehandlung sollte man seinen Kunde die Möglichkeit auf 
eine Art “Debugging” geben. Es sollte direkt ersichtlich sein ob der eigene 
angebotene Dienst online ist und ob es die verwendeten  Dienste sind. So teilt 
man dem Kunden direkt mit wo der Fehler liegt und ob man dafür zuständig ist.

\subsection{Which Customer(s) Do You Need to Know About?}

Die letzte Frage die der Artikel stellt ist über welche Kunden man in Kenntnis 
sein sollte. Es ist klar dass man seine C1 Kunden authentifizieren möchte 
zwecks kommerziellen Nutzens.  Bleibt noch aus was man über die C2, C3...Cx 
Kunden wissen möchte. Dabei müssen rechtliche Punkte beachtet werden. So kann 
es unter Umständen Gesetz sein zu wissen wer den eigenen Service nutzt. Oder 
man möchte selektiv nur bestimmte C2 Kunden blocken um in Verhandlungen mit 
C1 Kunden treten zu können.

\subsection{Conclusion}

Jetzt ist eine aufregende Zeit Software zu designen, speziell im Rahmen von verteilten Systemen. Es öffnet sich
eine Anzahl an Möglichkeiten die aber auch eine Reihe an Überlegungen mit sich ziehen. Dieser Artikel dient als
Einführung in einige dieser Überlegungen. 


\subsection{Fazit}

Der Artikel erreicht meines Erachtens seine Intention eine erste Einführung in das Thema
``Distributed Systems'' zu geben und schafft es Fragen zum Thema aufzuwerfen sowie weiter
darüber nachzudenken. An machen Stellen wird anscheinend absichtlich auf weitere Details
verzichtet um eine Diskussion im Architecture Journal Forum zu erzeugen. So finde ich 
dass ein sehr wichtiger Aspekt komplett ausgelassen wird, das Thema Sicherheit. Auch 
wenn die zusammengesetzten Dienste einen Mehrnutzen für den Benutzer bedeuten, sollte
man sich heute im klaren darüber sein, dass es für viele von Interesse ist wo persönliche 
Daten abgelegt werden und wie damit umgegangen wird. Im Szenario 1 wird die  Mobilfunknummer
eines Kunden von  ``Adventure Works'' über ``Fabrikam'' zu ``Contoso Mobile'' übermittelt. Mir
würde sich dabei sofort die Frage stellen, wer hat dann welche Rechte an meiner Mobilfunknummer?
Vielleicht ist diese Frage aber eher europäischer Natur. Interessant ist, dass der Artikel von
2008 sich zwar als zukunftsweisend sieht, meines Erachtens wurden die beschriebenen
Mechanismen jedoch schon vorher genutzt. So hatte sich die Webseite www.geizhals.at
schon vor 2008 zu solch einem Dienst entwickelt wie er in Szenario 2 beschrieben wird.
Ein Preisvergleich verschiedener Onlineanbieter mit zusätzlichen Funktionen wie
Händler übergreifender Warenkorb, Preisstatistik und weiterem. Ansonsten gibt der Artikel gute
Tipps und Denkanstöße zum Design einer zusammengesetzten Dienstseite, jedoch keine konkreten 
Lösungen. Wobei dies auch nicht die Absicht in ersten Hinsicht ist.